home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / programmer / 3381 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  7.5 KB
  1. Path: grafix.xs4all.nl!john.hendrikx
  2. Date: Wed, 07 Feb 96 22:44:34 GMT+1
  3. Newsgroups: comp.sys.amiga.programmer
  4. Distribution: world
  5. Subject: Re: Amiga doesn`t need Planar!
  6. MIME-Version: 1.0
  7. Content-Type: text/plain; charset=iso-8859-1
  8. Content-Transfer-Encoding: 8bit
  9. From: john.hendrikx@grafix.xs4all.nl (John Hendrikx)
  10. Message-ID: <john.hendrikx.4coj@grafix.xs4all.nl>
  11. Organization: Grafix Attack BBS Holland
  12.  
  13. In a message of 06 Feb 96 Michael Van Elst wrote to All:
  14.  
  15.  >> Not really.  I hardly call a write-mask 'hardware' anyway,
  16.  
  17.  MVE> Ah. Every extra hardware that chunky needs is "hardly hardware" at
  18.  MVE> all.
  19.  
  20. So isn't it true that Chunky is quite useable with a lot less hardware?
  21.  
  22.  MVE> Do you see a biased view here ?
  23.  
  24. How could I possibly deny this, I mean seeing how Chunky has taken over almost
  25. every computer platform surely would have its effect.
  26.  
  27.  >> Of course?  What kind of platform do you have in mind anyway?  I'm
  28.  >> talking Pentium's, P6, 68060's, PPC's, etcetera...  memory is slow for
  29.  >> these fast processors.
  30.  
  31.  MVE> You mean the x * 100MByte/s of memory bandwidth on the graphics card
  32.  MVE> is slow ? It is just the CPU that is slow compared to the graphics
  33.  MVE> hardware.
  34.  
  35. So what is 'x'?  Without it this statement could mean anything.
  36.  
  37. However, the bus TO the gfx-card is slow, so doing a few extra tests'and
  38. branches for each pixel plotted would not make things any slower, and thus
  39. wouldn't be a big overhead, like you claimed in the first place.
  40.  
  41.  >> If you want multiple layers with planar you LOSE colors. Ie, 8 bitplanes
  42.  >> = 256 colors.  2x 4 bitplanes = 32 colors.
  43.  
  44.  >> Not with Chunky,
  45.  
  46.  MVE> You are comparing apples and bananas. You say: "if you can use the
  47.  MVE> harware to produce a layered display you lose colors if you use the
  48.  MVE> same amount of memory" but "if you render the whole display you can
  49.  MVE> simulate layering with software".
  50.  
  51. If the hardware limits you to some arbitrary number of colors when it comes to
  52. layering displays then you can be glad that the display is Chunky as this kind
  53. of display can do quite rapid layering of its own without losing any colors.
  54.  
  55.  MVE> Don't you see that this has nothing to do with chunky vs. planar ?
  56.  
  57. I wouldn't say nothing, however if you want a specific end-result then you
  58. better choose carefully what hardware to use.  I mean, if you require a fast
  59. 256 color 3d view, with a cockpit overlayed then you either chose a 8-bit
  60. Chunky card, or a 9-16 bit Planar card.
  61.  
  62.  >> For consoles yes, they don't have a 'big CPU' to handle this kind of
  63.  >> stuff.
  64.  
  65.  MVE> And why not ? Because it is too expensive for consoles. The special
  66.  MVE> hardware that is NOW available is much cheaper and can do the same.
  67.  
  68. Special hardware can only do what is popular, the latest effects will still be
  69. CPU based at first before they become popular, IF they become popular that is.
  70.  
  71.  >> is a much better way to solve these kind of speed-problems.  What use is
  72.  >> that expensive DSP when it is just sitting there having nothing to do,
  73.  
  74.  MVE> You mean the $10 DSP that handles the audio ports ? Or the $100 DSP
  75.  MVE> that decodes the network video streams ?
  76.  
  77. Why not add a $80 PPC603/66 and get an overall speed boost, not just at
  78. handling video streams, or the things the OS uses the DSP for.  For most users
  79. this will safe them more time on overall.
  80.  
  81.  >> or when apps
  82.  >> simply not use it but use their own CPU based routines?
  83.  
  84.  MVE> C0d3r stuff ?
  85.  
  86. No, lack of foresight in the OS, or lack of upgrades.  If there is no OS
  87. supported way to do something a DSP can handle then you could hardly call
  88. writing your own CPU based MPEG decoder c0d3r stuff.
  89.  
  90.  >> Adding an extra CPU is more expensive, but it can do so much more.
  91.  
  92.  MVE> Usually it is weaker than special hardware and hardly used too.
  93.  
  94. Depends on the OS.  It would be hard to get a single-processor based OS to make
  95. good use of multiple processors, but if it is was there right from the
  96. beginning the benefits could be quite high.  Tasks involving frequent Harddisk
  97. access for example divide their CPU power over 3 different tasks in AmigaOS
  98. already.  And almost any task can be split over multiple CPU's with a bit of
  99. forethought.  But it would be hard to add now, and make decent use of it, even
  100. though it is never too late to start as I think multiprocessor designs are
  101. going to move into the homes real soon now.
  102.  
  103.  >> Certainly
  104.  >> it will not be as fast as a real MPEG or JPEG decoder, but then again,
  105.  >> what use is a JPEG decoder if you want to do texturemapping, or doing
  106.  >> complex sound effects?
  107.  
  108.  MVE> What if you want to do texturemapping _and_ real-time MPEG ?
  109.  
  110. Let me interpret your questions in the wrong way:  there is only one DSP which
  111. can only handle one of these tasks at the time.  The other task will have to
  112. wait.  With multiple CPU's you will atleast get something done, but slower of
  113. course, after all you're doing multiple things at the same time.
  114.  
  115. Also, why would CPU + DSP be faster at TMap + MPEG than 2 CPU's?  The CPU doing
  116. the TMapping might actually have time left to help with the MPEG decoding.
  117.  
  118.  >> Do I really need to explain this in detail for you?  Do you really don't
  119.  >> see WHY a tmapped or shaded polygon is drawn one pixel at the time (as in
  120.  >> multiple calculations are performed per pixel to give each pixel the
  121.  >> correct look)?
  122.  
  123.  MVE> Now, for me texture mapped polygons are drawn in strips of 1-32 pixels
  124.  MVE> because that's the length of the pattern buffer. It doesn't matter that
  125.                                        ^^^^^^^^^^^^^^
  126. They will be stored one by one in the pattern buffer, maybe storing a few in
  127. registers before writing them to the pattern buffer, but the loop which
  128. calculates the pixels will clearly be working at one pixel at the time.
  129.  
  130.  MVE> pixels might be computed individually but these are hardly _drawn_
  131.  MVE> individually.
  132.  
  133. "Drawn" to me means writing them to memory.  For me the C2P step is not the
  134. thing which draws the scene to the screen, instead the TMapping routine which
  135. builds the Chunky buffer is the thing that draws them.
  136.  
  137.  >> There is no need for a bandwidth increase.  With a faster CPU you can
  138.  >> just display more CPU intensive effects, the bandwidth could remain the
  139.  >> same.  In other words, with a 486/25 I could play 'DOOM' on my clone at a
  140.  >> decent speed, now with my Pentium/90 I can play 'Magic Carpet' at a decent
  141.  >> speed.  The gfx-card is just as fast, still I gained a lot by upgrading my
  142.  >> CPU.
  143.  
  144.  MVE> And that's an effect of chunky hardware if "number of memory accesses"
  145.  MVE> is all that matters as you said ?
  146.  
  147. For Chunky the number of memory accesses is what determines the maximum speed
  148. in FPS of a certain screentype.  The CPU
  149. -and- Hardware determine how cool the effects can be.
  150.  
  151. For Planar the hardware determines how cool the effects can be, and determines
  152. the maximum speed as well.  The CPU is not involved.
  153.  
  154. The situation with Amiga is amusing however:  We now have the situation that
  155. the CPU actually IS involved in how cool the effects can be with Planar.  This
  156. is because our Planar is actually so damned slow and so old that the steady
  157. upgrade of CPU speed has actually closed the ENORMOUS gap between Planar
  158. hardware speeds and CPU speeds of the same age.  The speed difference is so big
  159. that the CPU can afford to do a complete C2P conversion to get new cool effects
  160. to be used with the old planar system.
  161.  
  162. Grtz John
  163.  
  164. -----------------------------------------------------------------------
  165.  John.Hendrikx@grafix.xs4all.nl   TextDemo/FastView/Etc... development
  166. -----------------------------------------------------------------------
  167. -- Via Xenolink 1.981, XenolinkUUCP 1.1
  168.